1. Field of the Invention
The invention relates generally to managing access to shared resources and in particular to managing access to shared resources in a database.
2. Background Information
In information technology systems, processes such as software applications that access relational databases typically use either a pessimistic locking approach or an optimistic locking approach in accessing shared data for introducing updates. Both approaches manage concurrent access to shared resources, with different benefits and drawbacks. With pessimistic locking, a process that needs to update a shared resource (such as a row or table in a database) requests an exclusive lock on the resource. The lock can be achieved, for example, that ensures that write access from other processes is denied. The lock manager then reads the resource, applies any required changes/updates and releases the exclusive lock to allow other processes access.
With optimistic locking, instead of exclusively locking the resource, each process reads a timestamp or version number associated with the shared resource. Whatever process changes the state or content of a shared resource, it also raises the version number or updates the timestamp with the current time, so that other processes are notified that a change has been performed, and do not overwrite this change if they find that they are working with an older version of the same resource. Just before applying a change, each process reads the timestamp or version number again and checks it was changed since the first time it was read by that process. If the timestamp or version number has changed (indicating potential changes to the resources other processes), the process gives up the update.
Pessimistic locking is generally utilized for databases exposed to concurrency issues, and it is likely that multiple processes attempt to update the same resource concurrently. Optimistic locking is generally utilized for databases that have low or no concurrency issues, so that it is not worth locking exclusively a resource because most likely there will be no concurrent updates (if concurrency arises, it is acceptable that one of the concurrent processes gives up the update, returns an error message, and tries again later).
A mix of the above approaches has also been utilized, wherein resource locking involves first applying optimistic locking, and if that fails, then switching to applying pessimistic locking.
However, a disadvantage of such approaches is complex. Another disadvantage is that such approaches typically force a process to execute a desired database transaction multiple times. This is unacceptable when a process is also executing other actions (which may be out of the scope of the database), and such actions cannot be undone in pure optimistic locking or done again in the mixed approach.